Telecommunications services provided over an IP Connectivity Access Network (IP-CAN) can be subject to charging and policy control mechanisms. This includes Quality of Service (QoS) control. Accordingly, some telecommunications systems incorporate so-called Policy and Charging Control (PCC) architectures to provide this control. For example, 3GPP TS 23.203 V8.6.0 describes such a PCC architecture in respect of packet flows in an IP-CAN session established by a user terminal through an Evolved 3GPP telecommunications system, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. FIG. 1 illustrates schematically an example of the PCC architecture described in 3GPP TS 23.203 that comprises a Policy and Charging Enforcement Function (PCEF), a Bearer Binding and Event Reporting Function (BBERF), a Policy and Charging Rules Function (PCRF), an Application Function (AF), an Online Charging System (OCS), an Offline Charging System (OFCS), and a Subscription Profile Repository (SPR).
The PCRF is a functional element that encompasses policy control decision and flow based charging control functionalities, a combination of the functionality of the Policy Decision Function (PDF) and the Charging Rule Function (CRF) defined in release 6 of the 3GPP specification. A PCRF can be implemented as a standalone node and behaves as a Policy Decision Point (PDP), or Policy Server (PS), that stores user data related to QoS enforcement, access control lists, etc. The PCRF provides policy and charging control for the media components negotiated between the user terminal and the AF. The PCRF receives session and media related information from the AF and informs the AF of traffic plane events. The PCRF also provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF. The PCRF can provision PCC rules and PCC decisions to the PCEF via the Gx reference point. Criteria such as the QoS subscription information may be used together with policy rules such as, service-based, subscription-based, or pre-defined PCRF internal policies to derive the authorized QoS to be enforced for a service data flow. The PCRF PCC decisions may be based on one or more of the following:                information obtained from the AF via the Rx reference point, e.g. the session, media and subscriber related information;        information obtained from the PCEF via the Gx reference point, e.g. IP-CAN bearer attributes, request type, subscriber related information and location information;        information obtained from the SPR via the Sp reference point, e.g. subscriber and service related data;        information pre-defined in the PCRF; and        information obtained from BBERF via the so-called Gxx reference point.        
The PCEF is a functional entity that behaves as a Policy Enforcing Point (PEP) for enforcing decisions instructed by the PCRF and the OCS. The PCEF provides service data flow detection (based on the service data flow filter filters defined in the PCC rules) to capture and analyse any user and signalling traffic, to identify the user and to capture details of the service(s) being used. The PCEF can then communicate this information to the PCRF over the Gx interface, to the OCS over the Gy interface, and to the OFCS over the Gz interface. The PCEF enforces QoS control according to the QoS authorised by the PCRF. The PCEF is typically deployed functionally between an access gateway giving access to a packet data network and an application server giving access to a particular service or set of services. The PCEF is preferably physically co-located within the gateway node implementing the IP access to the PDN. As such, in a GPRS core network the PCEF is located within the GPRS Gateway Support Node (GGSN), whilst in the case of a CDMA2000 network the PCEF may be located in a Packet Data Serving Node (PDSN), and in a WLAN network the PCEF may be located in a Packet Data Gateway (PDG).
The BBERF functionality includes bearer binding, uplink bearer binding verification and event reporting to the PCRF. For example, in a GPRS core network the bearer binding mechanism associates the PCC rule with the PDP context that is to carry the service data flow. When GPRS Tunnelling Protocol (GTP) is used between the BBERF and the PCEF then bearer binding is performed by the PCEF. Alternatively, when Proxy Mobile IP (PMIP) is used between the BBERF and the PCEF, instead of GTP, then bearer binding is performed by the BBERF.
The OCS provides authorization for the usage of network resources based on the provisioned data and the user activity information it receives from PCEF. This authorization must be granted by the OCS prior to the actual resource usage. When receiving a network resource usage request, the network assembles the relevant charging information and generates a charging event towards the OCS in real-time. The OCS then returns an appropriate resource usage authorization over the Gy interface. The resource usage authorization may be limited in its scope (e.g. volume of data or duration) therefore this authorization may have to be renewed from time to time as long as the user's resource usage persists. The OCS can support time, volume and event-based charging.
The AF is an element offering applications that require policy and/or charging control of the IP-CAN user plane behaviour. The AF communicates with the PCRF over the Rx interface to transfer dynamic session information (e.g. a description of the media to be delivered in the transport layer) required for PCRF decisions, as well as to receive IP-CAN specific information and notifications about IP-CAN bearer level events. One example of an AF is the P-CSCF of the IP Multimedia Core Network (IM CN) subsystem. In the case of a P-CSCF, the information communicated over the Rx interface is derived from the P-CSCF session information (e.g. SDP when SIP is used for signalling) and it mainly includes media components. A media component comprises a set of IP flows, each of which is described by a 5-tuple, the media type and required bandwidth.
The SPR contains all subscriber/subscription related information needed for subscription-based policies and IP-CAN bearer level PCC rules by the PCRF. The Sp interface allows the PCRF to request subscription information related to the IP-CAN transport level policies from the SPR based on a subscriber ID and other IP-CAN session attributes.
Considering further a state-of-the-art PCEF, in short this can performs the two steps of:
1) inspecting the content of a received (originating or terminating) data packet, and
2) classifying the packet according its content and to some static rules, where these rules are predefined in the PCEF for specific packet contents.
Step 1) usually involves a two-step process carried out by an “analysis engine”. The first step is optionally to associate the packet with a user, either the packet sender (source IP address) or the packet recipient (destination IP address). The second step is to determine, as accurately as possible, a protocol to which the packet corresponds. This might involve a relatively “shallow” inspection (e.g. inspecting some layer 3 and 4 headers of the packet, such as transport and/or network layer headers), and/or a deep packet inspection (DPI) (e.g. inspecting the packet content beyond the headers cited above, including the packet payload), or the application of some heuristics to the packet content (e.g. to identify characteristics or behavioural patterns).
Step 2) is carried out by a “classification engine” in order to determine a specific treatment for the data packet (e.g. at the level of: applicable charging, applicable QoS, content filtering, etc). The PCEF uses the packet context and stateful flow analysis information obtained during the inspection phase to classify the packet into the right service class. WAP navigation, MMS traffic, HTTP browsing, and downloads are examples of service classes. The classification rules in the PCEF are static rules. This classification step essentially places packets into specific service sessions within a user session.
An example of a service class configured in the PCEF might be a service class for HTTP. This could be specified as follows:
service-class 100pattern web-browsingURL http://www.google.esendcredit-control onQoS Gx-driven...end
In this example, the type of protocol to match is HTTP. The PCEF has a set of pre-defined patterns, and the pattern that corresponds to HTTP protocol is called “web-browsing”. Within this pattern, one or more URLs may be specified. In this case, the URL to match is “www.google.es”. When any packet matches the conditions in the service class (that is, HTTP protocol and URL=www.google.es), the actions specified in the service class will be taken, namely credit control will be performed (against a pre-defined Credit Control server), and a request to the PCRF will be performed in order to obtain the QoS for this service class.
A further example of a service class definition might be as follows:
service-class 105pattern P2Pprotocol BitTorrentendQoS Gx-driven, Local (peakBW=100)...end
Here, the pattern used is a peer to peer protocol, more specifically “BitTorrent”. When the PCEF detects a BitTorrent packet, it will apply the locally specified QoS, that is, a peak bandwidth of 100 kbps unless a QoS is received via the Gx interface in which case the Gx-driven QoS will take precedence.
It will be apparent that, in order to implement a detailed level of control covering a broad range of users and services, the classification rules defined in the PCEF tend to be both complex and numerous. The content of a received packet must be inspected against a huge number of classification rules before it can be properly classified into a service session inside a user session. This can cause delays in packet routing, and increases the processing load in the node performing the inspection/classification.
Conventional PCEF classification engines use what are effectively statically defined rules, and the analysis of the packets versus the classification rules is made in the order that these rules are configured. Typically, once a matching rule is identified for a packet, the search is terminated and the actions specified in the matching rule applied. Consider for example the case where the analysis engine determines that a packet matches to the HTTP protocol, and that the classification engine has extracted the URL from the HTTP protocol header. The classification engine must then look up the rules in the rules list, one by one, to identify if one of these rules contains a match for the identified protocol and the extracted URL.